<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Context',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/12/21.jpg" alt="Traffic" class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<h3>Question 0: Generics</h3>
		<p>
			Generics are classes that don&apos;t directly specify the data type that their methods operate on.
			Instead, a placeholder type name is put in the method signatures.
			These same placeholders are used in the signature of the class (Bertrand, 2018), similar to how parameters act as placeholders for values in a function.
			The value is passed in upon calling the method.
			In the same way, the type names are passed in upon instantiation of the generic class.
			From then on, the object will behave as if the methods had been declared as only accepting arguments of the specified type or types (Oracle, n.d.).
			However, other objects of this class can be instantiated specifying other types.
			This allows you to avoid declaring multiple classes that differ only in the types of the parameters of their methods.
		</p>
		<p>
			For example, in Java, a generic class might look like this:
		</p>
		<blockquote>
<pre><code>class KeyValueStore&lt;K, V&gt; {
	private key: K[];
	private value: V[];
	function relate(K key, V value, int array_key) { 
		this.key[array_key] = key;
		this.value[array_key] = value;
	}
}</code></pre>
		</blockquote>
		<p>
			In the setup above, the <code>relate()</code> method takes three arguments.
			The third argument is always an integer, but the first and second argument depend on the specific object.
			When the <code>KeyValueStore</code> object is instantiated, the types of the first two arguments are chosen.
			For example, if you instantiated an object using the code <code>KeyValueStore&lt;String, int&gt; example = new KeyValueStore&lt;String, int&gt;();</code>, the <code>example</code> object will only be able to accept a string and an integer as the first two arguments to the <code>relate()</code> argument.
			No other argument types will be allowed.
			However, in this (incomplete) example, you&apos;d be able to have one object to relate strings to integers and another to relate integers to booleans without needing to declare two separate classes.
		</p>
		<h3>Question 1: Open recursion</h3>
		<p>
			The term &quot;open recursion&quot; is a confusing one, and doesn&apos;t intuitively match what it actually means.
			Basically, it refers to the property of object methods to mutually see other methods.
			This allows the methods to call one another, no matter what order the methods are declared in within the class definition.
			Additionally, methods can call other methods that <strong>*haven&apos;t been declared within that class*</strong>.
			Instead, these methods might be defined in a subclass.
			From the sounds of it, not all languages provide this feature (Nystrom, 2013).
		</p>
		<p>
			My last example was in Java, so let&apos;s try another language this time: $a[PHP].
			Open recursion in $a[PHP] can be done via the <code>\$this</code> pseudo-variable or the <code>static</code> key word:
		</p>
		<blockquote>
<pre><code>&lt;?php
namespace st\\y\\example;

abstract class parent_class {
	function call_other_method(): void {
		\$this->other_method();
	}
}

class child_class extends parent_class {
	function other_method(): void {
		echo &quot;Other method called!\\n&quot;;
	}
}</code></pre>
		</blockquote>
		<p>
			In this example, an object of class <code>\\st\\y\\example\\child_class</code> can have their <code>call_other_method()</code> called, and it&apos;ll perform just fine.
			It doesn&apos;t matter that the class defining the <code>call_other_method()</code> didn&apos;t define the <code>other_method()</code> method, nor does it matter that the <code>other_method()</code> method was defined after the <code>call_other_method()</code> method.
			It still works just the same.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Bertrand, C. (2018, June 27). Coding Concepts - Generics. Retrieved from <a href="https://dev.to/designpuddle/coding-concepts---generics-34cf"><code>https://dev.to/designpuddle/coding-concepts---generics-34cf</code></a>
			</p>
			<p>
				Nystrom, B. (2013, August 26). What is &quot;Open Recursion&quot;? – journal.stuffwithstuff.com. Retrieved from <a href="https://journal.stuffwithstuff.com/2013/08/26/what-is-open-recursion/"><code>https://journal.stuffwithstuff.com/2013/08/26/what-is-open-recursion/</code></a>
			</p>
			<p>
				Oracle. (n.d.). Generic Types (The Java™ Tutorials &gt; Learning the Java Language &gt; Generics (Updated)). Retrieved from<a href="https://docs.oracle.com/javase/tutorial/java/generics/types.html"><code>https://docs.oracle.com/javase/tutorial/java/generics/types.html</code></a>
			</p>
		</div>
	</blockquote>
</section>
<section id="Minetest">
	<h2>Minetest</h2>
	<p>
		It occurred to me this morning that I can&apos;t really work on any other mods until I get this colour palette thing sorted out.
		After all, with this new setup, I&apos;ll probably be paletting all nodes I define in some way.
		The main issue is that there are basically five palettes now, and each one falls back to the next one due to the feature that preserves colour in dropped items.
		A node with a smaller palette can always drop an item with a larger palette, and the correct colour should be used in such cases.
	</p>
	<p>
		So the four-bit palette had to incorporate the three-bit palette, while the five-bit palette had to incorporate the four-bit palette.
		None of the colours from the current five-bit palette (aside from those from the three-bit palette) make sense to use in the four-bit palette, so I had to come up with new colours.
		I thought I knew the only logical choices, given the constraints, but then that messed with the five-bit palette.
		I had to re-design the five-bit palette as well.
		And once I had the four- and five-bit palettes right, I&apos;d need to get the six-bit palette figured out.
		From there, the only remaining palette, the eight-bit palette, would simply fall into place, using the colours remaining from my mathematically-chosen set.
	</p>
	<p>
		But yeah.
		The only idea I had for the four-bit palette, which doubles the number of colours from the three-bit palette, was to add less-extreme (in other words, greyer) versions of the eight colours of the three-bit palette.
		I just wasn&apos;t sure how to work with that in the five-bit palette.
		In my defence though, the five-bit palette was a major challenge when dealing with the three-palette system as well, and I was never actually happy with the results.
		This was the sort of thing to contemplate while I&apos;m out and about though; it wasn&apos;t something that stating at my palette on the computer screen would help with.
		I constantly think about things as I run errands and such, so this would give me somewhere productive to aim those thoughts.
	</p>
	<p>
		I&apos;d already found a few useful properties about the number of colours in the newly-discovered palette sizes, though taking advantage of those properties would break the graceful degradation feature I&apos;d set up for when nodes of a smaller palette drop items of a larger palette.
		(The larger palettes currently degrade gracefully to fit the smaller palettes, making small-to-large (the reverse) conversion perfect and automatic.)
	</p>
	<p>
		So while I was out today, I did contemplate long and hard about the palettes.
		I came to a few big conclusions that have helped me figure out exactly what I need to do.
		First of all, context of a palette is <strong>*everything*</strong>.
		One thing I&apos;ve been trying to make work well is compatibility with Minetest Game&apos;s dyes.
		However, I&apos;ve also been trying to find mathematical justification for the colours I choose, do to the mathematical way in which my own dye system works.
		Without mathematical reasoning, my palette simply won&apos;t make sense with my dye system.
		However, these two goals are incompatible.
		There <strong>*is*</strong> no mathematical justification for the colours Minetest Game&apos;s dye system uses.
		As best I can tell, it&apos;s just a collection of colours someone thought would look cool.
		At the same time, the <code>minequest</code> mod I&apos;m working on makes zero sense outside the context of Minetest Game.
		It will <strong>*never*</strong> come into contact with my dye system!
		It relies on specifics within Minetest Game that would never be allowed in Palette Game.
		So why does it need to have any mathematical justification for its colours whatsoever?
		It just needs to work with Minetest Game&apos;s dye system, and that&apos;s <strong>*it*</strong>.
		To top it off, the chests will have sixteen colour choices for technical reasons, and there are fifteen Minetest Game dyes.
		It&apos;s nearly a perfect match.
		All I have to do is throw in an &quot;undyed&quot; colour, and everything there is perfect.
		Any mod I make that makes no sense outside the context of Minetest Game doesn&apos;t need to try to cram in both Minetest Game dye support and mathematical justification together.
	</p>
	<p>
		The context thing goes even further though.
		The very compatibility between the five palettes is something that I don&apos;t think I&apos;d ever use.
		The issue is that I&apos;ve been trying to develop general-purpose palettes for use in most, if not all, cases.
		If for some reason, I need compatibility between two paletted items, I can define compatible palettes specifically for those items.
		Though for technical reasons relating to how dropped items get counted, I would never have such a use case myself.
		I&apos;ve been pouring so much energy into setting up features that I never intend to use.
		What a waste.
		But anyway, with that nonsense thrown out, I don&apos;t even have to jumble the pallets any more.
		The colours can be ordered in a much more intuitive way.
		The one exception is that the palette still needs to be inverted.
		The intuitive place to put black is at index zero, as there is the lowest amount of red, green, and blue in that colour.
		Then other colours are incremented from there.
		However, due to a technical issue in the engine, perfect white has to be at index zero to deal with a bug.
		So instead, perfect white is placed at index zero and other colours are instead reached through <strong>*decrementing*</strong>.
		Still, it fixes all problems I have in all palettes I need to work with.
		Having one, contextless set of palettes for every use case just isn&apos;t going to get the good results I want.
	</p>
</section>
END
);
